The present invention relates generally to the field of distributed transaction processing, and more particularly to use of connection status techniques to reduce occurrences of in-doubt occurrences of distributed transaction processing.
A distributed transaction is the execution of one or more units of work distributed on different systems. A distributed commit protocol is required to ensure that the effects of a distributed transaction are atomic, that is, either all the effects of the transaction persist or none persist, whether or not failures occur. A well-known commit protocol is the two-phase commit (2PC) protocol. For transaction processing applications such as hotel reservations, airline reservations, stock market transactions, or banking applications, the commit processing takes up a substantial part of the transaction. Therefore, the performance of a commit protocol substantially affects the transaction volume that a system can support.
The “last agent commit process”, is an optimization of the distributed two-phase commit protocol, and is a widely used optimization to improve the performance of commit processing. Last agent commit optimization reduces time-consuming message sending and log writes, between a transaction manager (TM), coordinating the transaction, and a remote resource participant within the distributed processing system. In providing an optimization of the two-phase commit protocol, the last agent commit process removes the prepare phase message for the last participant, and the coordinating participant sends a commit message to the last participant, with all other participants having prepared and confirming a commit vote to proceed. The last participant determines the last vote of whether to proceed with the commit of the transaction process or back-out and roll back the transaction. The last agent commit process creates a potential large period of in-doubt failure between the last remote write and receipt of a commit or back-out (rollback) message.
The period between when a distributed transaction participant has prepared its own recoverable state and voted yes to commit, and the time when it is instructed to perform the commit (or perform a back-out if some failure or no vote was received at some point within the subsequent distributed prepare processing), is known as the “in-doubt” window. Units of work are said to be in-doubt during this time, as they are not yet aware of whether they will need to commit or back out, and access to data involved in the transaction remains locked-out for use by other pending transactions.